Implementation of XATTR on JFFS2 and SELinux

CE Linux Forum Technical Jamboree(Oct 27, 2006)

Kohei Kaigai, OSS Promotion Center, NEC
<kaigai@ak.jp.nec.com>

[translated by ikoma; see original slides for figures]
---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 2

Contents

* Introduction <==
* Structure of XATTR/JFFS2
* Feedback from the Community
* Use of XATTR/JFFS2 and Future Works

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 3

Who on earth am I?

* Developing around SELinux
  - Improved scalability of SELinux (2004)
    + SELinux then was slow
    + Realized lockless reference using RCU
  - Supported XATTR on JFFS2 (2005-2006) <==
    + JFFS2 = Filesystem for Flash ROM
    + To use SELinux, XATTR must be supported
  - Developing PostgreSQL for SELinux (in progress)
    + Information flow control integrated with OS

---------------------------- = ----------------------------
[see original slide; page 4]
Copyright (C) 2006, NEC Corporation 4

In the first place, what is SELinux? (1)


user space
  process A
  process B

system calls
  read()
  write()
  ioctl()
  xxx()

kernel space
  vfs_read() function
     LSM hook
       What about read?  - OK
  sys_ioctl() function
     LSM hook
       What about ioctl?  - NG

SELinux

security policypolicydb


* Check if executable at system call execution
* Even root checked (=mandaotory access control)
* Rules managed in integrated manner with security policy
* TE/RBAC/MLS features offered

---------------------------- = ----------------------------
[see original slide; page 5]
Copyright (C) 2006, NEC Corporation 5

In the first place, what is SELinux? (2)

signal

process A
unconfined_t

  read
  getattr
  ioctl

  file X
   user_home_t
     type

  file Y
     user_home_t


  getattr

process B
postgresql_t

 read getattr
 ioctl write

    file Z
      postgresql_db_t


*security policy*
allow unconfined_t user_home_t:file {read getattr ioctl};
allow unconfined_t postgresql_db_t:file {getattr};
allow postgresql_t postgresql_db_t:
file {read getattr ioctl write};
allow unconfined_t postgresql_t:process {signal};


Give types to all process resources
=> Enforcement of "type", i.e. TE(Type Enforcement)

---------------------------- = ----------------------------
[see original slide; page 6]
Copyright (C) 2006, NEC Corporation 6

In the first place, what is XATTR?

* XATTR=eXtended ATTRribute

hello.c

(contents)
#include <stdio.h>
int main(){
puts("hello world!");
}


(attributes)
owner: kaigai
group:users
permission:0755
file size 123 bytes
last update: 10/28 10:11:22



(extended attributes(XATTR))
security.selinux                             -- name
= user_u:object_r:user_home_t:s0             -- value
system.posix_acl_access
= u:rw-:ymj
                            -- any value can be stored with any name

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 7

Support of XATTR for JFFS2 - development started (1) -

* Intimacy between embedded systems and SELinux
 -- Even if security patch released
  -> there are cases where patches cannot be applied immediately
 -- A huge volume of machines of identical configuration released into market
  -> Threat of 0-day attack is unpredictable
 -- Directly connected to threat against life/property
* Then, what is necessary?
 -- Busybox commands for SELInux
 -- Reduction of security policy size
 -- XATTR support for diskless file system <-

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 8

Support of XATTR for JFFS2 - development started (2) -

* What is the development trends in original community?

  - Asked actually
    at Jul, 2005 Ottawa Linux Symposium

Stephen Smalley says:
1. For busy box, Cocker's patch should be available
2. For smaller policy size, just now developing
3. Somebody seems to have implemented XATTR for JFFS2 using hidden files

David Woodhouse says:
No plan now to implement XATTR for JFFS2; contribution would be welcome

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 9

XATTR Status (Kernel 2.6.18)

* For servers/workstations
  - Ext2, Ext3, XFS, ReiserFS, JFS
* For embedded systems
  - JFFS2 (Added in kernel 2.6.18)
    + Filesystem developed to use Flash ROM etc. effectively
    + Design taking account of robustness and lifetime of media
* Network filesystem
  - NFSv3, NFSv4, CIFS (But supporting only POSIX-ACL)
* Pseudo-filesystem
  - FUSE

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 10

Contents

* Introduction
* Structure of XATTR/JFFS2 <==
* Feedback from the Community
* Use of XATTR/JFFS2 and Future Works[see original slide; page 11]

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 11

What filesystem is JFFS2 like? (1)

* Features of Flash ROM
  - Recognized as MTD device
  - Limited number of writing: Around 100 thousand times
  - Data once wrinten can only be erased as an Erase Block
* Features of JFFS2
  - Implemented as a upper layer of MTD device
  - Designed not to heavily use particular area on the media
      (Write-once-like architecture)
  - Garbage collector reallocates data on media, allowing to erase per Erase Block

[figure]
Erase Block
Total amount

---------------------------- = ----------------------------
[see original slide; page 12]
Copyright (C) 2006, NEC Corporation 12

What filesystem is JFFS2 like? (2)

Write-once-like architecture

Writing unit: node
 * Recordable in arbitary length
 * Checing consistensy with CRC code
 * 7 types including inode type
    JFFS2_NODETYPE_INODE
    JFFS2_NODETYPE_DIRENT
    JFFS2_NODETYPE_CLEANMARKER
    JFFS2_NODETYPE_PADDING
    JFFS2_NODETYPE_SUMMARY
    JFFS2_NODETYPE_XATTR
    JFFS2_NODETYPE_XREF


Node common header
                        32bit
    +---------------------+---------------------+
+0  | JFFS2_MAGIC_BITMASK |     node type       |
    +---------------------+---------------------+
+4  |                Total Length               |
    +-------------------------------------------+
+8  |              Header CRC Code              |
    +-------------------------------------------+

---------------------------- = ----------------------------
[see original slide; page 13]
Copyright (C) 2006, NEC Corporation 13

What filesystem is JFFS2 like? (3)
want to update here:

inode no.: 123
version no.: 1

inode no.: 123
version no.: 2

inode no.: 123
version no.: 3

* update = increment version number + append
* There are more than one nodes with an identical inode No. and different version No.
* Nodes with older version No. are ignored
 -> Later collected by GC and the region becomes available again after Erase Blocks deleted

---------------------------- = ----------------------------
[see original slide; page 14]
Copyright (C) 2006, NEC Corporation 14

What filesystem is JFFS2 like? (4)

Getting tight

Append (copy) to Erase Blocks for save

GC:Garbage Collector

Delete the Erase Block in a lump

---------------------------- = ----------------------------
[see original slide; page 15]
Copyright (C) 2006, NEC Corporation 15

What filesystem is JFFS2 like? (5)

All media scanned when mounted

ino=123
version=1 (dead)

ino=123
version=2 (dead)

ino=123
version=3 (alive)

EBS(Erase Block Summary) feature
Just reading Summary at the end of Erase Blocks tells which kinds of nodes are written where
=>Faster mounting

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 16

What filesystem is JFFS2 like? (6)

* Write-once-like architcture
 -- Not use heavily a specific area on media -> long lasting!
 -- GC reallocates nodes, based on the characteristics of Flash-ROM
* Robustness
 -- No Super Block at specific location
 -- CRC checked while reading data
* There is a drawback:
 -- Must scan whole media when mounting FS
    + EBS (Erase Block Summary) support remedys the situation

---------------------------- = ----------------------------
[see original slide; page 17]
Copyright (C) 2006, NEC Corporation 17

Basic Structure of XATTR on JFFS2 (1)

* Definition of node types storing XATTR

JFFS_NODETYPE_XATTR node
                         32bit
     +---------------------+-----------------------+
+0   | JFFS2_MAGIC_BITMASK |  JFFS2_NODETYPE_XATTR |
     +---------------------+-----------------------+
+4   |                Total Length                 |
     +---------------------------------------------+
+8   |              Header CRC Code                |
     +---------------------------------------------+
+12  |            XID(XATTR Identifier)            |
     +---------------------------------------------+
+16  |                Version no.                  |
     +----------+----------+-----------------------+
+20  | xprefix  | Name Len |       Data Len        |
     +----------+----------+-----------------------+
+24  |               Data CRC Code                 |
     +---------------------------------------------+
+28  |               Node CRC Code                 |
     +---------------------------------------------+
     |         XATTR Name/Value pair               |
     |                                             | Name Len + Data Len + 1
     |                               +-------------+
     |                               |  Padding    |
     +-------------------------------+-------------+
                                       



JFFS2_NODETYPE_XREF node
                         32bit
     +---------------------+-----------------------+
+0   | JFFS2_MAGIC_BITMASK |  JFFS2_NODETYPE_XREF  |
     +---------------------+-----------------------+
+4   |               Total Length                  |
     +---------------------------------------------+
+8   |             Header CRC Code                 |
     +---------------------------------------------+
+12  |                  inode no.                  |
     +---------------------------------------------+
+16  |            XID(XATTR Identifier)            |
     +-------------------------------------------+-+
+20  |     xseqno(XATTR Sequencial Number)       |*|  <--Delete Marker
     +-------------------------------------------+-+
+24  |                Node CRC Code                |
     +---------------------------------------------+

---------------------------- = ----------------------------
[see original slide; page 18]
Copyright (C) 2006, NEC Corporation 18

Basic Structure of XATTR on JFFS2 (2)

inode

ino=160
/etc/shadow

ino=110
/bin/ps

ino=101
/bin/cat

ino=119
/bin/vi

xref

XREF
ino=160
XID=95

XREF
ino=160
XID=80

XREF
ino=110
XID=60

XREF
ino=101
XID=60

XREF
ino=119
XID=60


xattr

XID=80
security.selinux =
system_u:object_r:shadow_t:s0

XID=60
security.selinux =
system_u:object_r:bin_t:s0

XID=95
system.posix_acl_access =
user:kaigai:r--

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 19

Basic Structure of XATTR on JFFS2 (3)

* inode and xattr have N:M relation
 -- More than one inode shares name/value pairs of xattr
 -- Efficient storage/memory usage
* Keeps existing node structure
 -- Just ignored as "unknown node" on old kernel
* Can store:
 -- SELinux label (security.*)
 -- POSIX ACL (system.posix_acl_{accessUdefault})
 -- Arbitary user type data (user.*, trusted.*)

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 20

Approaches proposed so far

* Method using hidden file
 -- By Lorenzo Herna'ndez Garci'a-Hierro
 -- Same way as used in ReiserFS
* Given up because it is on the JFFS3 roadmap & bugs cannot be cleaned up
* Extension to directory entry
 -- By Ma Yun
 -- Posted just 6 hours before I posted patch
     (It was lucky that this was not a patent)
 -- Put Name/Value pairs of XATTR into directory entry
* Cannot share the same Name/Value pair
* In SELinux, a lot of same Name/Value pairs are used
* Undesirable to change meaning of JFFS2_NODETYPE_DIRENT node

---------------------------- = ----------------------------
[see original slide; page 21]
Copyright (C) 2006, NEC Corporation 21

Data Structure of XATTR on JFFS2 (1)

jffs2_xattr_datum object
XID=123, version=8
node   xname/xvalue


Name/Value pair
security.selinux =
system_u:object_r:...


jffs2_raw_node_ref object
offset next_in_ino

jffs2_raw_node_ref object
offset next_in_ino


         1 to 1 correspondence to node on media
jffs2_raw_node_ref object
offset next_in_ino


kernel memory space
---------------------
format on media



XID=123
version=7
system_u:object_r:...

XID=123
version=6
system_u:object_r:...


XID=123
version=8
system_u:object_r:...

jffs2_raw_xattr struct defines format

---------------------------- = ----------------------------
[see original slide; page 22]
Copyright (C) 2006, NEC Corporation 22

Data Structure of XATTR on JFFS2 (2)


jffs2_xattr_ref object
node
ic xd

jffs2_inode_cache object
ino=321

jffs2_xattr_datum object
XID=123


jffs2_raw_node_ref object
offset next_in_ino

jffs2_raw_node_ref object
offset next_in_ino

jffs2_raw_node_ref object
offset next_in_ino

kernel memory space
---------------------
format on media

ino=321
XID=123
xseqno=1018

ino=321
XID=123
xseqno=1016

ino=321
XID=123
xseqno=1020

jffs2_raw_xref struct defines format

---------------------------- = ----------------------------
[see original slide; page 23]
Copyright (C) 2006, NEC Corporation 23


Data Structure of XATTR on JFFS2 (3)

jffs2_inode_cache object
ino=321
node
xref

jffs2_xattr_ref object

jffs2_xattr_ref object

jffs2_xattr_ref object

jffs2_raw_node_ref object
offset next_in_ino

jffs2_raw_node_ref object
offset next_in_ino

jffs2_raw_node_ref object
offset next_in_ino

kernel space
--------------------------
format on media

ino=321
version=7
system_u:object_r:...

ino=321
version=6
system_u:object_r:...

ino=321
version=8
system_u:object_r:...

jffs2_raw_inode struct defines format

---------------------------- = ----------------------------
[see original slide; page 24]
Copyright (C) 2006, NEC Corporation 24

Data Structure of XATTR on JFFS2 (4)

getxattr(file, xname, buffer, size)
user space
-----------------
kernel space

VFS
vfs_getxattr(dentry, xname, buffer, size)
inode_operation->getxattr

generic_getxattr(dentry, xname, buffer, size)

do_jffs2_getxattr(inode, xprefix, xname, buffer, size)

jffs2_inode_cache object

jffs2_xattr_ref

jffs2_xattr_datum
Name/Value pair

jffs2_xattr_ref

jffs2_xattr_datum
Name/Value pair

jffs2_xattr_ref

jffs2_xattr_datum
Name/Value pair

search Name/Value pair matching to xname

---------------------------- = ----------------------------
[see original slide; page 25]
Copyright (C) 2006, NEC Corporation 25

Data Structure of XATTR on JFFS2 (5)

ǒ
scan

jffs2_raw_node_ref

jffs2_raw_node_ref

jffs2_raw_node_ref

jffs2_inode_cache
or
jffs2_xattr_datum
or
jffs2_xattr_ref
??????

reference required in direction node -> inode/xattr/xref

save_xattr_datum()
save_xattr_ref()

jffs2_raw_node_ref

jffs2_raw_node_ref

jffs2_raw_node_ref



struct jffs2_raw_node_ref
{
struct jffs2_raw_node_ref *
next_in_ino;
uint32_t flash_offset;
};

---------------------------- = ----------------------------
[see original slide; page 26]
Copyright (C) 2006, NEC Corporation 26

Data Structure of XATTR on JFFS2 (6)

jffs2_inode_cache struct
+----------------------------------------------+
|           void *always_null;                 |
+----------------------------------------------+
|       struct jffs2_raw_node_ref *nodes;      |
+-----------+-----------+----------------------+
| u8 class; | u8 flags; | u16 state;           |
+-----------+-----------+----------------------+
|                    u32 ino;                  |
+----------------------------------------------+
RAWNODE_CLASS_INODE_CACHE

jffs2_xattr_datum struct
+----------------------------------------------+
|              void *always_null;              |
+----------------------------------------------+
|      struct jffs2_raw_node_ref *nodes;       |
+-----------+-----------+----------------------+
| u8 class; | u8 flags; |     u16 xprefix;     |
+-----------+-----------+----------------------+
|            struct list_head xindex;          |
+----------------------------------------------+
RAWNODE_CLASS_XATTR_DATUM

jffs2_xattr_ref struct
+----------------------------------------------+
|             void *always_null;               |
+----------------------------------------------+
|      struct jffs2_raw_node_ref *nodes;       |
+-----------+-----------+----------------------+
| u8 class; | u8 flags; |     u16 unused;      |
+-----------+-----------+----------------------+
|                 u32 xseqno;                  |
+----------------------------------------------+
RAWNODE_CLASS_XATTR_REF

* Many of jffs2_raw_node_ref objects are generated
 -- Not allowed to increase the size of struct
* Head part of the structure is a common format
 -- Seeing class variable can tell the type of the object
 -- Area obtained by reducing state variable originally of 32 bit width into 16 bits
  -> size of jffs2_inode_cache struct increased only size of pointer to jffs2_xattr_ref (+4 bytes)
 -- Most processing of garbage collector can be refactored

---------------------------- = ----------------------------
[see original slide; page 27]
Copyright (C) 2006, NEC Corporation 27

Processing when Mounted (1)

scan through media

XID=123
version=4

XID=123
version=5

XID=123
version=6
Node with the largest version no. is the right one

EBS(Erase Block Summary) Feature

Writes contents to be scanned into at the end of each Erase Block beforehand

-> Just read here -> Faster mouting time

Merged into the mainline ahead while developing xattr

So XATTR had to support this

---------------------------- = ----------------------------
[see original slide; page 28]
Copyright (C) 2006, NEC Corporation 28

Processing when Mounted (2)

jffs2_xattr_datum
(Loaded state)
Name/Value pair

--unload_xattr_datum()-->
<--load_xattr_datum()--

jffs2_xattr_datum
(Unloaded state)

do_verify_xattr_datum() function

jffs2_xattr_datum
(unverified state)
* XATTR marker(16bit)
* XID(32bit)
* version no.(32bit)
* offset(32bit)
* node length(32bit)


XATTR info included in summary

  jffs2_sum_xattr_flush
+0+------------------------+
    |        nodetype        |
+2+------------------------+
    |          XID           |
+6+------------------------+
    |        version         |
+10 +------------------------+
    |         offset         |
+14 +------------------------+
    |         totlen         |
+18 +------------------------+

jffs2_sum_xref_flush
+0+------------------------+
|        nodetype        |
+2+------------------------+
|         offset         |
+6  +------------------------+

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 29

Contents

* Introduction
* Structure of XATTR/JFFS2
* Feedback from the Community <==
* Use of XATTR/JFFS2 and Future Works

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 30

Processing when to Delete Nodes (1)

* In earlier implementations (-revision.5) by Kaigai:
 -- xattr_datum and xattr_ref always has single node
 -- When to delete node, overwrites node header with 0xff
 -- Somebody pointed out that this can not be used with NAND flash memory
* Changed to implementation using "delete marker" (revision.6)
 -- Mark the node with the largest version no. as "This XATTR has been deleted"
 -- This XATTR will be skipped when mounted next time
* Issue of atomicity of XATTR deletion
* XATTR which has been set is treated as "deleted"

---------------------------- = ----------------------------
[see original slide; page 31]
Copyright (C) 2006, NEC Corporation 31

Processing when to Delete Nodes (2)

* Issue of atomicity of XATTR deletion
 -- Modified to treat as "deleted" XATTR not referenced from any inode

Processing to delete XATTR

Write out JFFS2_NODETYPE_XATTR with deletion marker

Write put JFFS2_NODETYPE_XREF with deletion marker

* Before writing out XREF,
  - what if media becomes full?
  - what if OS crashes?

JFFS2 anyway scans all nodes on the media when mounted
-> Use "number of XREFs referring to XATTR" as "deleted flag"

---------------------------- = ----------------------------
[see original slide; page 32]
Copyright (C) 2006, NEC Corporation 32

Processing when to Delete Nodes (3)

* Written XATTR treated as "deleted"


Write name="security.selinux"value="system_u:..." to ino=200

Name/Value pair exists on XATTR cache

  NO(XID=123)

  Write JFFS2_NODETYPE_XATTR(XID=123)

YES(XID=123)

Write JFFS2_NODETYPE_XREF(ino=200, XID=123)

1. Remove XATTR(XID=123) from inode
2. As the XATTR is shared, it is not removed at this timing
3. Set the identical Name/Value pair
-> Generate XREF with same ino/xid combination

Who owns the version no.?
->
If version no. specific to XREF is used, "deleted" one may be judged to be newer

So, give a globally unique sequence number (xseqno/31bit)

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 33

David Woodhouse's Refactoring

* Size of jffs2_raw_node_ref reduced (16bytes->8bytes)
  -- Interface to get physical node modified

* Format of jffs2_inode_cache modified
  -- GC implementation refactored among inode/xattr/xref
->
David Woodhouse: Inode part modified, so please modify xattr/xref implementation accordingly to new format

Now becomes coding with clearer view of entire filesystem

---------------------------- = ----------------------------
[see original slide; page 34]
Copyright (C) 2006, NEC Corporation 34

Garbage Collection (1)

jffs2_reserve_space()
Available area is less than requested

jffs2_garbage_collect_pass()


   jffs2_garbage_collect_trigger()

      Available block number : 2%-3%

Garbage Collector
(jffs2_gcd_mtd0)

kernel_thread()

mount

scan


jffs2_raw_node_ref
offset
next_in_ino

non-NULL  NULL

jffs2_inode_cache
or
jffs2_xattr_datum
or
jffs2_xattr_xref

Identifiable with member variable "class"

---------------------------- = ----------------------------
[see original slide; page 35]
Copyright (C) 2006, NEC Corporation 35

Garbage Collection (2)

jffs2_raw_node_ref

ic/xd/xref

    Up to here, common processing path both for inode and for XATTR

jffs2_xattr_datum

  Yes

  Is the node Latest?

    Yes

    jffs2_garbage_collect_xattr_datum()
    => save_xattr_datum()
    Write XATTR into a new block

  No


No

jffs2_xattr_ref

  Yes

  Is the node Latest?

    Yes

    jffs2_garbage_collect_xattr_ref()
    => save_xattr_ref()
    Write XREF into a new block

       Increment version no.

  No

No

jffs2_garbage_collect_live()
Garbage collection of JFFS2_NODETYPE_INODE JFFS2_NODETYPE_DIRENT

---------------------------- = ----------------------------
[see original slide; page 36]
(C) 2006, NEC Corporation 36

Garbage Collection (3)

jffs2_xattr_datum and jffs2_xattr_ref can not be freed immediately

XID=100
version=4

XID=100
version=6

XID=100
version=9
(Latest)

XID=100
version=5

Refers to jffs2_xattr_datum object to judge if garbage

jffs2_xattr_datum
XID=100
(JFFS2_XFLAGS_DEAD)
<- Flag meaning that "it is not referred from anywhere"



jffs2_free_jeb_node_refs()
(processing just before deleting Erase Block)

jffs2_raw_node_ref

    Node included in Erase Block

ic/xd/xref

  Common processing path both for inode and for XATTR

XATTR?
  Yes
    jffs2_release_xattr_datum()
No

XREF?
  Yes
    jffs2_release_xattr_ref()
No

jffs2_del_ino_cache()

---------------------------- = ----------------------------
[see original slide; page 37]
Copyright (C) 2006, NEC Corporation 37

Garbage Collection (3)

jffs2_xattr_datum and jffs2_xattr_ref can not be freed

As all referring nodes deleted, now can be freed

jffs2_xattr_datum
XID=100
(JFFS2_XFLAGS_DEAD)
<- Flag meaning that "it is not referred from anywhere"


jffs2_free_jeb_node_refs()
(processing just before deleting Erase Block)

jffs2_raw_node_ref

  Node included in Erase Block

ic/xd/xref

  Common processing path both for inode and for XATTR

XATTR?
  Yes
    jffs2_release_xattr_datum()

No
XREF?
  Yes
    jffs2_release_xattr_ref()
No

jffs2_del_ino_cache()

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 38

Isn't it Redundant?

* Length restriction of XATTR Name/Value pair

  #define XATTR_NAME_MAX 255
  #define XATTR_SIZE_MAX 65536

  -- In XATTR/JFFS2, dependent on EraseBlock size
NOR-Flash64KB-128KBNAND Flash8KB-16KB

  -- "Can not implement XATTR spanning over more than one nodes?"

  -- "Is it really necessary!?"

* About 100 bytes at most are enough for SELinux or POSIX-ACL
* Total size of XATTR in Ext2/3 is Block Size (4K bytes)
  -- "Seems reasonable when Ext2/3 requires such"

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 39

XATTR/JFFS2 Merged in Kernel 2.6.18

And total 20 patches are merged in kernel 2.6.18 as XATTR/JFFS2 implementation

[JFFS2][XATTR] Fix memory leak in POSIX-ACL support
[JFFS2][XATTR] Fix xd->refcnt race condition
[JFFS2][XATTR] coexistence between xattr and write ...
[JFFS2][XATTR] Fix wrong copyright
[JFFS2][XATTR] Re-define xd->refcnt as atomic_t
[JFFS2][XATTR] Fix memory leak with jffs2_xattr_ref
[JFFS2][XATTR] rid unnecessary writing of delete marker.
[JFFS2][XATTR] Fix ACL bug when updating null xattr ...
[JFFS2][XATTR] using 'delete marker' for xdatum/xref ...
[JFFS2][XATTR] Fix obvious typo
[JFFS2][XATTR] Handling the duplicate JFFS2_NODETYPE ...
[JFFS2][XATTR] remove redundant pointer cast in acl.c
[JFFS2][XATTR] remove '__KERNEL__' from acl.h
[JFFS2][XATTR] remove senseless comment
[JFFS2][XATTR] Unify each file header part with any ...
[JFFS2][XATTR] '#include <linux/list.h>' was added ...
[JFFS2][XATTR] Remove jffs2_garbage_collect_xattr(c, ic)
[JFFS2][XATTR] Remove 'struct list_head ilist' from ...
[JFFS2][XATTR] Add a description about c->xattr_sem
[JFFS2][XATTR] remove typedef from posix_acl related ...
[JFFS2][XATTR] XATTR support on JFFS2 (version. 5)

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 40

Contents

* Introduction
* Structure of XATTR/JFFS2
* Feedback from the Community
* Use of XATTR/JFFS2 and Future Works <==

---------------------------- = ----------------------------
[see original slide; page 41]
Copyright (C) 2006, NEC Corporation 41

Installed SELinux on OpenZaurus

Security contexts are displayed

kernel: 2.6.16-oz + KaiGai patch
Policy: SPDL(Simplified Policy)
libselinux, libsepol, /sbin/init, busybox etc. are installed.

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 42

OLPC(One Laptop Per Child) Project

* PCs for children in developing countries!
  -- Solution to digital divide
  -- Promotion and enlightenment of Linux
* $100 PC
  -- Orders of millions times several countries
  -- 512MB Flash ROM + JFFS2 for storage device
  -- Use of SELinux to enhance security
* Threat of zero day attack is serious as there will be a huge amount of machines of an identical configuration
  - They may be used in the environment where patches cannot be applied easily
  - To use SELinux, XATTR on JFFS2 must be supported

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 43

Future Works

* To reduce memory footprint of POSIX-ACL for JFFS2
  -- To implement referring to POSIX-ACL for Ext2/3
  -- XATTR in JFFS2 can cache name/value pairs
* To develop SELinux commands for busybox
  -- chcon, setsebool, setenforce etc.
* To developemnet policy specific for embedded systems
  -- Reference Policy assumes use on servers
  -- Use of attributes is key to reduce policy size
  -- Security policy for distro not for servers

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 44

Any Question?

---------------------------- = ----------------------------
Copyright (C) 2006, NEC Corporation 45

Appendix -- History of XATTR/JFFS2 Development --

* Revision.1'05/08/23
  -- Prototype of XATTR/JFFS2; GC not implemented yet
* Revision.2'05/09/07
  --Added GC support for XATTR nodes
* Revision.3'05/09/28
  -- Fixed bug of deadloack in Revision.2
* Revision.4'05/12/28
  -- Support of Posix-ACL and XATTR initialization in kernel 2.6.14
* Revision.5'06/05/09
  -- Added EBS (Erase Block Summary) support
  -- git tree based
* Revision.6'05/06/24
  -- Modified to node deletion by "Delete Marker"

---------------------------- = ----------------------------
